遠距與共處工作並非簡單的二分法，而是有許多團隊分佈模式，每種模式都有不同的取捨和適合的有效技術。雖然無法確定明確的證據，但我認為大多數團隊以共處的方式工作會更有效率。但你可以透過使用分散工作模式來建立更有效率的團隊，因為這能讓你接觸到更多的人才庫。

軟體專案是資助和組織軟體開發的熱門方式。它們將工作組織成暫時性的、只建置的團隊，並以商業案例中預測的特定效益進行資助。產品模式則使用持久性的、構思-建置-執行團隊，處理持續性的業務問題。產品模式允許團隊快速重新定位，縮短端到端週期時間，並透過使用短週期迭代來驗證實際效益，同時維護軟體的架構完整性以維持其長期效能。

在理想狀態下，產品模式組織由鬆散連結、自主的團隊組成，這些團隊能快速回應已表達和未表達的使用者需求。然而，偶爾會出現需要多個團隊協調才能回應的機會。如果沒有有效管理，結果將會造成收入損失、客戶不滿意和團隊產能浪費。我們將回應這些機會的組織性舉措稱為計畫。在本文中，我們將透過一個失敗計畫的範例，分享我們在產品模式組織中管理計畫的經驗。

平台團隊獨特地依賴其他團隊來確保其平台的採用 - 將程式碼變更納入其他團隊的程式碼庫對其成功至關重要。有各種模式可供跨團隊協作，而選擇正確的模式取決於平台採用的階段，以及團隊和程式碼庫接受外部影響的能力。

康威定律（由梅爾文·康威於 1968 年提出）指出，系統的設計受到其設計者溝通模式的約束。Birgitta、Mike、James 和我討論了此原則的含義，以及我們在職業生涯中如何看到它的發揮。我們討論了它對微服務概念的影響、與業務能力保持一致的重要性，以及逆康威操作的角色。

模組化架構可以改善軟體交付嗎？是的！ - 但有一些但書。本文記載了一家企業的歷程，他們著手將其架構轉移到更模組化的架構，以緩解其成長的痛苦。他們發現模組化是一個多方面的解決方案，不僅擴及架構，還擴及業務溝通管道、團隊拓撲和有效的開發人員體驗。透過密切注意這些因素，該企業得以大幅提升其行動應用程式的交付效能。

任何重要的軟體開發工作都需要執行數項不同的活動：分析、使用者體驗設計、開發、測試等。以活動為導向的團隊圍繞這些活動組織，因此您有專門的團隊負責使用者體驗設計、開發、測試等。以活動為導向承諾許多好處，但軟體開發通常最好透過 OutcomeOriented 團隊來完成。

對齊地圖是組織資訊散熱器，有助於視覺化持續工作與業務成果之間的對齊。這項工作可能是常規功能新增或技術工作，例如重新建構或償還技術債務或改善建置和部署管道。團隊成員使用對齊地圖了解其日常工作旨在改善哪些業務成果。業務和 IT 贊助者使用它們來了解持續的工作如何與他們關心的業務成果相關。

軟體開發中未決的問題之一是決定軟體邊界是什麼。（瀏覽器是否為作業系統的一部分？）許多服務導向架構的支持者認為應用程式即將消失 - 因此未來的企業軟體開發將與組裝服務有關。

我不認為應用程式會消失，原因與應用程式邊界如此難以繪製相同。基本上應用程式是社會建構

雙峰 IT 是有缺陷的概念，認為軟體系統應分為這兩個不同的類別進行管理和控制。

• 前端系統（參與系統）應最佳化以進行快速功能開發。這些參與系統需要快速回應不斷變化的客戶需求和業務機會。應容忍缺陷，因為這是快速開發週期的必要成本。
• 後端系統（記錄系統）應最佳化以確保可靠性。作為記錄系統，重要的是不要出現損害企業的缺陷。因此，您會減慢變更速度。

邊界脈絡是領域驅動設計中的核心模式。這是 DDD 的策略設計部分的重點，其重點在於處理大型模型和團隊。DDD 透過將大型模型分為不同的邊界脈絡並明確說明它們之間的相互關係來處理大型模型。

以業務能力為中心的團隊是其工作長期與業務的特定領域保持一致的團隊。只要所述業務能力與業務相關，團隊就會存在。這與專案團隊形成對比，專案團隊僅持續到交付專案範圍的時間為止。

我遇到過各種程式碼擁有權的方案。我將它們分為三大類

我所推崇的軟體架構從業人員幾乎都對該領域的任何一般法則深表懷疑。良好的軟體架構非常特定於脈絡，分析在各種環境中以不同方式解決的權衡取捨。但如果有一件事他們都同意，那就是康威定律的重要性與力量。它足夠重要，可以影響我遇到的每個系統，而且它足夠強大，以至於如果你試圖對抗它，你註定會失敗。

當有人在尋找構成頂尖企業軟體開發人員的因素時，通常談話可能會轉向對框架和語言的了解，或者可能是理解複雜演算法和資料結構的能力。對我來說，程式設計師或開發團隊最重要的特質之一是我所稱的客戶親和力。這是開發人員對軟體所解決的業務問題以及生活在該業務世界中的人們感興趣和親近的程度。

敏捷軟體開發打破了需求分析、測試和開發之間的一些隔閡。部署、運作和維護是其他與軟體開發流程的其他部分有類似隔閡的活動。DevOps 運動旨在消除這些隔閡，並鼓勵開發和運作之間的協作。

一個常見的問題是大型專案是否可以使用敏捷技術。畢竟，許多敏捷方法都是針對較小的專案設計的，而它們所抵制的重量級想法在較大的專案中更為需要。

我使用外行程式設計師這個術語來表示在不認為自己是程式設計師的情況下進行程式設計的人。一個花費大量時間處理試算表的人正在進行程式設計，通常是非常密集的程式設計。然而，她通常不會稱自己為程式設計師，也不會考慮花很多時間學習如何更好地進行程式設計。

贊助軟體開發的人通常對開發指標（例如速度或部署到生產的頻率）不太感興趣。他們更關心軟體將提供的業務效益，例如降低人工成本、改善銷售轉換率、提高客戶滿意度，即業務成果。以成果為導向的團隊是有權且有能力提供業務成果的團隊，此類團隊擁有具備執行實現成果所需所有活動的能力的人員。相比之下，以活動為導向的團隊既沒有設備也沒有授權這樣做。他們只能執行實現成果所需的幾項活動之一。

關於結對程式設計的一些常見誤解。

通訊技術的進步導致越來越多團隊採用遠距優先的風格工作，而這股趨勢也因 Covid-19 疫情的強制隔離而更加蓬勃發展。但遠距運作的團隊仍然能從面對面的聚會中獲益，而且應該每隔幾個月就舉辦一次。

想像一個徵才的情境。有兩位候選人都有幾年的經驗。藍方是一位在您偏好的設計風格中具備良好廣泛設計技能的人（對我來說，這會像是 DRY、明智地使用模式、TDD、具溝通力的程式碼等，但實際清單並不重要，重要的是符合您的偏好）。然而，她對您正在使用的特定平台技術一無所知。紅方是一位對這些議題知之甚少（或不感興趣）的人，但對您的平台非常了解，例如語言中的邊界案例、有哪些可用函式庫、手指在工具上自然移動。假設其他一切條件都相同（除了像這樣的思想實驗之外，這是不可能的），而且您的團隊沒有這個候選人可能填補的明顯漏洞。您會比較偏好哪一位？

軟體的一大好處是，人們似乎想要它，而且希望很快就能得到它。組織通常會要求團隊加快軟體的生產速度，而且組織時不時會尋求以真正展現其承諾的方式提供協助，例如花錢為團隊增加更多人手。

將資訊豐富的程式模組化的最常見方法之一，是將其分為三個廣泛的層級：簡報（UI）、領域邏輯（又稱商業邏輯）和資料存取。因此，您經常會看到網路應用程式分為了解如何處理 HTTP 要求和呈現 HTML 的網路層、包含驗證和計算的商業邏輯層，以及整理如何管理資料庫或遠端服務中持續性資料的資料存取層。

去年我花了很多時間在 Thoughtworks 各處遊走，與許多專案的許多人交談。其中一個訊息讓我印象深刻，那就是輪調的價值。

上週我很榮幸在佛羅里達州遊走，在多場 Microsoft 架構會議中與 Dan Sandlin 和 David LeBlanc 交談。對於不認識 David LeBlanc 的人來說，他與 Michael Howard 合寫了非常受歡迎的書 撰寫安全程式碼。在每一場會議中，我都會針對 P of EAA（本週獲得 JavaWorld 獎項）進行演講/問答，而 David 會接著討論安全性。

讓我們想像一個 SOA 快樂的美好世界，其中企業的運算需求被分割成許多小型應用程式，這些應用程式彼此提供服務，以利有效協作。某個美好的早晨，一個消費者服務需要從供應商服務取得一些資訊。問題是，儘管供應商服務擁有取得此資訊所需的必要資料和處理邏輯，但它尚未透過服務介面公開該資訊。供應商有一個潛在服務，但實際上它尚未存在。

在我最近的 CodeOwnership 文章中，我描述了我思考程式碼擁有權問題的方式。我的許多軟體開發朋友都是極限程式設計師，而且傾向於支持集體程式碼擁有權。然而，這些類型的做法並非絕對，而且應該隨時根據當地考量進行調整。我的其中一位同事寄給我一則附有以下故事的備忘錄，我認為這是一個良好的指標，說明即使你是 XP 的忠實愛好者，也必須改變你的做法。（由於他在談論他的團隊，因此他希望保持匿名。）

自從我進入這個行業以來，軟體開發的概念已經從費力地編寫程式碼轉變為透過簡單組裝元件來建構強大的系統。這是一個有時會瞥見，但從未真正達成的目標，儘管許多技術都曾拋出工業再利用的誘餌。

任何大型軟體專案，例如大型公司的軟體資產，都需要很多人，而每當你有很多人的時候，你都必須找出如何將他們分成有效率的團隊。組成以商業能力為中心的團隊有助於軟體專案對客戶的需求做出回應，但所需的技能範圍常常讓這些團隊不堪負荷。團隊拓撲是描述軟體開發團隊組織的模型，由馬修·史凱爾頓和曼紐爾·派斯開發。它定義了四種形式的團隊和三種模式的團隊互動。此模型鼓勵健康的互動，讓以商業能力為中心的團隊在提供穩定的有價值軟體任務中蓬勃發展。

在過去幾年中，行動應用程式一直是軟體開發中的熱門項目。像許多軟體交付公司一樣，Thoughtworks 收到許多客戶要求我們為他們建構行動應用程式。然而，在大部分時間，當一家公司要求我們（或任何人）建構行動應用程式時，他們一開始就走錯了路。我想爭辯的是，在大部分情況下，即使你希望使用者與行動裝置互動，你也絕不應該考慮建構行動應用程式。相反地，你需要考慮建構一個可以在多個裝置上呈現的單一應用程式：行動裝置、桌上型電腦、平板電腦，或你的使用者可能使用的任何裝置。

兩披薩團隊是一個小型團隊，完全支援特定商業能力的軟體。這個術語之所以流行，是因為它用來描述亞馬遜如何組織其軟體人員。

在我整個職業生涯中所見到的穩定主題之一，就是軟體開發的本質和重要性。幾年前，一位潛在客戶告訴我們的業務員「軟體就像污水管，我希望它能可靠地運作，而且我不想知道細節」。這就是 Nicholas Carr 在 IT Doesn't Matter 中所談到的方法。在對比之下，我們為許多企業執行工作，其中 IT 已成為其業務更明確的策略推動者，讓他們能夠進入新市場或顯著增加其市場占有率。因此，IT 是像污水管一樣的實用工具，還是策略資產？